Microservices #
While there is no standard, formal definition of microservices, there are certain characteristics that help us identify the style.
Essentially, microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.
For a detailed explanation of Microservices, see Martin Fowler’s seminal approach to the subject here.The idea behind microservices is that many types of applications become easier to build and maintain when they are broken down into smaller, composable pieces which work together. Each component is developed separately, and the application is then simply the sum of its constituent components. This is in contrast to a traditional, “monolithic” application which is all developed all in one piece.
Microservice applications share some important characteristics:
- Small in size - microservices are focused on delivering a single goal well
- Messaging Enabled - the ability to communicate seamlessly with other services
- Bounded by contexts - maintain their own data
- Autonomously developed - can be developed in parallel to meet business needs
- Independently deployable - can be deployed without impacting other services
- Built and released with automated processes - near zero touch deployments
A Microservices approach is goal-oriented, solving the problem of systems that are too big. More specifically, the real value of microservices is realized when we focus on three key aspects — speed, safety, and scale. Every single decision you make about your software development ends up as a trade-off that impacts these ideals.
Microservices architectures enable speed, safety, and scale in several ways:
- As we decouple the business domain into independently deployable bounded contexts of capabilities, we also decouple the associated change cycles. As long as the changes are restricted to a single bounded context, and the service continues to fulfill its existing contracts, those changes can be made and deployed independent of any coordination with the rest of the business. The result is enablement of more frequent and rapid deployments, allowing for a continuous flow of value.
- Development can be accelerated by scaling the development organization itself. It’s very difficult to build software faster by adding more people due to the overhead of communication and coordination. Fred Brooks taught us years ago that adding more people to a late software project makes it later. However, rather than placing all of the developers in a single sandbox, we can create parallel work streams by building more sandboxes through bounded contexts.
- The new developers that we add to each sandbox can ramp up and become productive more rapidly due to the reduced cognitive load of learning the business domain and the existing code, and building relationships within a smaller team.
- Adoption of new technology can be accelerated. Large monolithic application architectures are typically associated with long-term commitments to technical stacks. These commitments exist to mitigate the risk of adopting new technology by simply not doing it. Technology adoption mistakes are more expensive in a monolithic architecture, as those mistakes can pollute the entire enterprise architecture. If we adopt new technology within the scope of a single monolith, we isolate and minimize the risk in much the same way that we isolate and minimize the risk of runtime failure.
- Microservices offer independent, efficient scaling of services. Monolithic architectures can scale, but require us to scale all components, not simply those that are under heavy load. Microservices can be scaled if and only if their associated load requires it.
There are many resources on the web concerning microservices and how they might be implemented. Rather than focusing on a specific implementation, it is better to start with general overview references such as:
